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SECTION  I 
INTRODUCTION 


One  of  the  steps  in  the  ESD/MITRE  computer  security  program  is 
the  certification  of  computer  systems  as  secure.  This  topic  was 
addressed  in  [1]  in  broad  terms,  introducing  the  notion  of  a chain  of 
correspondences  between  successive  representations  of  a computer 
system.  Such  a chain  begins  with  a mathematical  model  of  secure 
systems  and  proceeds  through  a formal  specification  of  the  system  to 
an  algorithmic  representation  and  finally  to  a machine  language 
version. 

In  [2],  a methodology  was  developed  to  prove  that  a formal 
specification  represents  a secure  design.  The  nature  and  role  of  the 
formal  specification  of  the  system  was  explored.  Using  the  design  of 
a security  kernel  for  the  PUP-1 1/A5  given  in  [3]  as  a basis,  the  need 
for  multiple  levels  of  formal  specification  was  explained.  Finally, 
the  validation  for  one  PDP-11/A5  security  kernel  function  at  the 
highest  level  of  formal  specification  was  presented  as  an  example  of 
the  application  of  the  methodology. 

In  this  report,  the  methodology  is  extended  to  lower  levels  of 
formal  specification.  The  notions  of  levels  of  formal  specification, 
and  correctness  of  an  implementation,  as  described  by  SRI  in  [A] , are 
particularized  to  our  context.  This  report  shows  how  to  construct  an 
algorithmic  representation  from  the  abstract  programs  arising  from  the 
use  of  the  SRI  technique. 
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SECTION  II 


BACKGROUND 


For  the  past  four  years,  MITRE  has  been  working  on  a project, 
sponsored  by  the  Electronic  Systems  Division  of  the  U.S.  Air  Force,  to 
develop  provably  effective  access  controls  for  data  in  computer 
systems.  Of  the  technical  areas  explored  in  this  project,  one  of  the 
most  formidable  has  been  the  technical  certification  of 
multlprogrammed  systems  that  permit  controlled  sharing  of  classified 
information. 

Security  threats  to  computers  operating  in  a single-level  mode 
are  fairly  well  understood.  Among  them  are  physical  damage,  various 
forms  of  eavesdropping,  and  misbehavior  of  trusted  personnel.  A 
multilevel  system  is  subject  to  an  additional  kind  of  threat,  from 
untrusted  or  partially  trusted  users  with  legitimate  access  to  the 
system  services.  Such  users  can  introduce  their  own  software  into  the 
system,  and  that  software  might  succeed  in  copying  classified 
information  from  one  place  to  another,  within  the  system,  that  is 
accessible  to  uncleared  users. 

A conceptual  approach  to  preventing  the  misuse  of  a multilevel 
computer  system  was  presented  plainly  in  an  EFD  study  [5] . The  idea 
was  to  present  all  system  users,  and  their  software,  with  a "black 
box"  that  mediates  all  access  to  data  stored  in  the  system,  and  which 
itself  could  not  be  modified  by  any  user.  This  was  referred  to  as  a 
reference  monitor. 

The  reference  monitor  refuses  all  attempts  at  unauthorized 
accesses.  Any  requests  to  change  access  authorization  also  have  to  be 
processed  by  the  reference  monitor.  To  the  user  software,  a reference 
monitor  may  have  the  functional  appearance  of  any  computer,  except 
that  ordinary  Instructions  refuse  to  carry  out  unauthorized  memory 
accesses,  and  there  are  additional  "instructions"  having  to  do  with 
authorization  changes. 

It  was  recognized  that  rules  for  determining  authorization  and 
for  handling  authorization  changes  would  have  to  be  formulated  and 
justified  rigorously.  Rules  were  sought  that  were  consistent  with  the 
DoD  policies  for  controlling  access  to  classified  documents.  An 
early.  Independent  effort  toward  this  end  was  by  Weissman  [6]  for  the 
ADEPT-50  system.  That  and  other  work  ([7],  [8])  Influenced  the 
Bell-LaPadula  model  developed  at  MITRE  [9] . 
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Given  a model,  it  was  by  no  means  clear  how  to  Implement  it  to 
produce  a reference  monitor.  The  uncertainty  about  what  exact  form 
the  implementation  should  take,  as  well  as  the  origins  of  the  data 
protection  problem  in  large  multiprogramming  and  time-sharing  systems, 
led  to  the  approach  of  Implementing  the  bulk  of  the  reference  monitor 
in  software.  The  hardware  and  software  implementing  the  reference 
monitor  are  called  the  kernel.  In  the  context  of  a particular 
machine,  the  reference  monitor  software  alone  may  be  called  the  kernel 
[10]. 


In  order  to  crystallize  the  problems  Involved  in  getting  from  a 
model  to  a kernel,  MITRE  undertook  to  lI^lplement  a kernel  on  a 
minicomputer  that  was  provided  with  adequate  hardware  protection 
features:  a PDP-11/45  with  Memory  Management  Unit  (for  segmentation 
with  access  mode  control).  The  lessons  learned  from  this  brassboard 
design  were  then  to  be  applied  to  the  design  of  a kernel  for  the 
Multics  time-sharing  system.  The  PDP-11/45  kernel  is  running,  in  an 
experimental  environment,  and  the  design  of  the  Multics  kernel  is 
underway. 

The  features  for  data  protection  available  on  a particular 
machine  determine  whether  an  efficient  reference  monitor  can  be 
implemented  on  it.  The  boundary  between  hardware  and  software 
responsibilities  in  the  implementation  of  a reference  monitor  is  also 
hardware  dependent.  Some  discussion  of  what  hardware  features  are 
desirable  may  be  found  in  [11]. 

Our  implementation  approach  can  be  outlined  as  a progression 


Figure  1.  Stages  of  Kernel  Representation 


along  four  stages  of  kernel  representation  as  shown  in  Figure  1,  from 
Burke  [1]. 

The  formal  specification  embodies  the  design  precisely,  in  order 
to  verify  that  it  satisfies  the  requirements  of  the  model,  and  to 
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provide  assertions  against  which  the  correctness  of  the  software  could 
be  verified.  The  specification  technique  of  Parnas  [12]  was  adopted. 
The  practicality  of  using  It  for  a significant  part  of  an  operating 
system  had  been  established  by  Price  [13].  A formal  specification  for 
a PDP-11/45  kernel  was  developed  from  the  model  through  the 
Interaction  of  design  Ideas  with  the  need  for  rigorous  verification. 
The  Initial  specification  In  Schiller  [14]  was  Influenced  by  the 
Multlcs  protection  mechanism  ([15],  [16]).  Subsequent  work 
streamlined  the  specification  to  a point  where  the  model  requirements 
could  be  verified. 

At  Case  Western  Reserve  University  a group  took  an  alternative 
"successive  refinement"  approach  with  their  model,  toward  the  goal  of 
a formal  specification  of  the  Multlcs  kernel  [17].  They  constructed  a 
series  of  models,  each  one  a valid  Interpretation  of  the  preceding 
one,  and  Including  more  of  the  details  necessary  for  an  Implementable 
specification.  Their  first  model  was  Influenced  by  and  Influenced  the 
MITRE  model. 


VERIFICATION  OF  THE  KERNEL  DESIGN 

A major  point  of  concern.  In  verifying  the  correspondence  of  a 
kernel  design  to  a model  for  protection  of  data.  Is  whether  all 
repositories  of  Information  have  been  Identified.  Initial  attempts  at 
rigorous  kernel  verification  failed  to  recognize  the  state  variables 
In  the  kernel  as  "objects",  l.e.,  repositories  of  Information. 
Ironically,  the  need  to  check  Internal  variables  had  already  been 
recognized  In  an  Informal  analysis  of  security  enhancements  for 
Multlcs  [18]. 

The  answer  to  the  object  Identification  problem  was  already 
Inherent  In  the  formal  specification  approach.  Regarding  the 
reference  monitor  as  a "black  box",  a formal  specification  for  It  Is 
adequate  to  explain  Its  observable  behavior.  The  formal  specification 
Includes  both  user-visible  and  hidden  state  variables.  The  former  are 
the  "outputs"  of  the  black  box,  and  the  latter  are  needed  Internally 
to  hold  additional  current  state  Information. 

It  suffices  to  Identify  all  state  variables  In  the  specification 
as  objects.  Any  Implementation  of  the  reference  monitor  will  be 
constrained  to  have  the  same  observable  behavior  with  regard  to 
user-visible  state  variable  values.  Even  If  Its  Internal  structure  Is 
quite  different,  with  different  hidden  state  variables,  there  should 
be  no  way  that  the  user  can  tell  the  difference  between  the 
Implementation  he  Is  using  and  the  black  box  specified.  If  the  black 
box  Is  secure  with  the  formally  specified  structure.  It  will  be  secure 
with  any  other  structure  producing  the  same  user-observable  behavior. 
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A real  Implementation  may  produce  certain  types  of  behavior  other 
than  the  values  of  designated  state  variables.  Response  times, 
electromagnetic  radiation,  CPU  panel  lights,  disk  head  actions,  and 
power  consumption  are  all  potential  channels  for  compromise  of 
information.  It  is  not  practical  to  verify  and  implement  a formal 
specification  with  all  such  emanations  either  eliminated  or  explicitly 
controlled.  Methods  for  identifying  and  controlling  significant 
channels  of  this  type  are  beyond  the  scope  of  this  report. 

A technique  for  carrying  out  an  analysis  of  the  formal 
specification,  with  all  state  variables  Identified  as  objects,  was 
described  in  Millen  [2] . The  main  consequences  of  this  technique  are 
(1)  the  use  of  a set  of  axioms  as  the  proper  formal  statement  of 
authorization  and  access  control  policy,  rather  than  rules  for 
handling  particular  requests;  and  (2)  the  need  for  an  austere  version 
of  the  formal  specification,  sufficient  to  explain  the  reference 
monitor  behavior,  but  devoid  of  premature  implementation  decisions 
(actually,  a certain  amount  of  unnecessary  detail  can  be  tolerated). 


THE  ALGORITHMIC  REPRESENTATION 

The  algorithmic  representation  is  a programming  language  version  / 
of  the  kernel.  This  report  focusses  on  the  technique  for  proceeding 
from  a relatively  simple  formal  specification  of  the  kernel  to  an 
algorithmic  representation.  We  are  using  the  design  methodology  of 
Robinson,  et  al.  [4]  developed  at  Stanford  Research  Institute.  SRI's 
technique  is  discussed  in  the  next  section. 

Like  SRI,  we  develop  the  specification  by  reexpressing  it  in 
lower  levels  of  abstraction,  using  so-called  abstract  programs  to  show 
the  implementation  of  each  level  in  terms  of  the  primitive  functions 
of  the  next  lower  level. 

The  abstract  programs  between  all  levels  are  gathered  together  to 
form  the  major  part  of  the  algorithmic  representation.  The 
algorithmic  representation  also  includes  mapping  functions  or 
subroutines  that  provide  the  user  with  the  black-box  outputs  specified 
at  the  user  Interface  level. 
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SECTION  III 


THE  SRI  METHODOLOGY 


The  SRI  methodology  begins  conceptually  (but  not  necessarily 
chronologically)  with  a formal  specification  of  a user  interface.  The 
formal  specification,  written  in  a notation  derived  from  Parnas  [12], 
has  V-functlons  to  store  state  information  and  0-functions  to  specify 
transformations  on  V-function  values  resulting  from  user  requests. 

Such  specifications  may  be  called  transition  specifications. 

A formal  specification  defines  an  abstract  machine  whose  state 
variables  are  the  V-function  elements,  whose  inputs  are  0-function 
calls,  and  whose  transitions  are  determined  by  the  transformations  or 
"effects"  specified  for  the  0-functions.  An  abstract  machine  could  be 
a real  computer  if  the  0-functions  happen  to  correspond  to  machine 
instructions,  but  the  abstract  machine  at  the  user  Interface  is  more 
likely  to  be  a kind  of  "virtual"  machine. 

More  details  of  the  implementation  strategy  are  Introduced,  one 
by  one;  memory  management,  process  swapping  register  allocation,  data 
structure,  etc.  Each  implementation  concept  yields  a level  of 
abstraction  (see  [19]),  with  its  own  primitives,  defining  its  own 
abstract  machine  or  a functional  area  within  an  abstract  machine. 

Each  machine  is  used  to  Implement  a higher  level  machine,  just  as  a 
computer  is  used  to  Implement  a subroutine.  To  get  an  idea  of  how 
many  levels  this  might  involve,  note  that,  in  their  work  on  a 
particular  operating  system  design  [4],  SRI  envisioned  thirteen  levels 
of  abstraction. 

The  implementation  of  each  machine  using  the  next  lower  machine 
was  specified  by  writing  an  abstract  program  for  each  0-function  in 
the  "upper"  level  machine  in  terms  of  "lower"  level  primitives. 
Abstract  programs  are  ordinary  programs,  in  some  unspecified  but 
simple  and  well-understood  programming  language.  Abstract  programs 
call  0-f unctions  instead  of  subroutines. 

An  abstract  program  can  be  either  correct  or  Incorrect  depending 
on  what  assumptions  have  been  made  about  the  correspondence  between 
data  structures  in  a level  and  their  implementation  in  the  next  lower 
level.  SRI  has  chosen  to  require  mappings  that  allow  one  to  determine 
all  the  state  information  in  each  abstract  machine  from  state 
information  available  in  the  next  lower  level  machine.  An  abstract 
program  is  correct  if  it  preserves  the  mapping  between  the  two 
adjacent  levels.  This  commutativity  condition  is  Illustrated  in 
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Figure  2,  where  f Is  the  mapping,  t is  the  upper  level  0-function 
call,  and  A(t,s)  is  the  abstract  program  implementing  t.  The 
commutativity  condition  is  the  equation 

t(f(s))  = f(A(t,s)(s)). 

This  form  of  the  condition  is  appropriate  when  f is  a function;  more 
generally,  f need  only  be  a relation.  The  commutativity  condition  is 
proved  using  well  known  techniques  for  proving  assertions  about 
programs  [20].  The  "input"  assertion  for  the  program  A(t,s)  is 
whatever  is  known  about  state  s,  and  the  "output"  assertion  is  the 
statement  that  the  new  lower  level  state  maps  to  the  upper  level  image 
state. 


') 

f 

0 

Figure  2.  Correctness  of  Implementation 


The  proof  methodology,  called  behavioral  Implementation,  is 
defined  in  Section  V.  It  is  a combination  of  the  more  general  notion 
of  behavioral,  or  black  box,  equivalence,  defined  in  Section  IV,  and 
the  technique  of  abstract  implementations. 

Here  is  a brief  outline  of  the  steps  proposed  in  this  report  to 
construct  a secure  algorithmic  representation  of  the  kernel: 

1.  Prove  that  the  upper  level  of  specification  is  secure.  The 
methodology  needed  to  do  this  is  detailed  in  [2] . 

2.  Design  lower  levels  of  specification. 

3.  For  each  level  of  specification  (except  the  lowest)  write  abstract 
programs  to  Implement  each  0-function  in  the  next  lower  level. 

4.  Prove  that  each  level  is  behavlorally  Implemented  by  the  next 
lower  level,  generating  Invariants  (relations)  as  needed  in  the 
proof.  A relation  asserting  the  identity  of  visible  state 
variable  values  must  be  Included. 
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5.  Prove  that  the  specific  initial  state  chosen  for  the  kernel 
satisfies  the  relations. 

6.  Write  and  verify  function  subprograms  to  calculate  the  values  of 
high  level  state  variables  appearing  in  abstract  programs. 

7.  The  set  of  all  the  abstract  programs,  with  0-functlon  calls 
regarded  as  subroutine  calls,  plus  the  function  subprograms  from 
step  6,  yield  an  algorithmic  representation  of  the  kernel. 
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SECTION  IV 


BEHAVIORAL  EQUIVALENCE 


This  section  discusses  a method  for  proving  the  equivalence 
between  two  abstract  machines,  called  behavioral  equivalence.  It  is 
applied  to  show  that  if  we  have  a secure  upper  level  machine  and  a 
lower  level  machine  that  is  behaviorally  equivalent  to  it,  then  the 
lower  level  machine  is  secure.  In  this  section  we  will  describe 
behavioral  equivalence  for  machines  with  the  same  set  of  inputs,  A 
later  section  will  show  how  to  apply  the  theory  when  one  machine  (the 
lower  level  one)  has  a more  primitive  set  of  inputs. 


DEFINITION  OF  BEHAVIORAL  EQUIVALENCE 

In  order  to  define  behavioral  equivalence  we  define  an  abstract 
machine  as  a quadruple  (S,sO,T,V).  S is  the  set  of  states  of  the 
machine.  We  assume  each  state  is  a vector  of  .state  variables.  sO  is 
the  initial  state  of  the  machine.  T is  the  set  of  Inputs.  These  will 
be  0-functlon  calls.  Not  shown  explicitly  is  the  transition  function 
taking  each  state  s to  the  next  state  st,  for  each  t in  T.  V is  the 
vector  of  visible  state  variables.  We  denote  by  V(s)  the  vector  of 
visible  state  variable  values  for  a state  s.  In  a machine  defined  by 
a Parnas  specification,  visible  state  variables  are  the  user-visible 
V-functlon  references.  The  user  may  be  able  to  deduce  information 
about  the  hidden  state  variables,  but  he  can  only  do  so  through  his 
observation  of  the  visible  state  variables. 

Say  we  are  given  two  different  abstract  machines,  of  which  one  is 
more  complicated  than  the  other,  l.e.,  is  "lower  in  level".  Assume 
that  we  would  like  to  prove  that  the  lower  level  machine  provides  a 
secure  Interface  to  its  users.  Specifically,  we  would  like  to  know 
that,  starting  with  a fixed  initial  lower  level  state,  sO,  and  an 
arbitrary  sequence  of  upper  level  inputs  tl,...,tn,  no  information  is 
ever  passed  from  a user-visible  state  variable  of  a given  security 
level  to  one  of  a lower  security  level  during  the  sequence  sO, 
sOtl, . . . ,sO(tl. . . tn)  of  states  in  the  lower  level  machine. 

A way  to  verify  security  for  a high  level  formal  specification 
was  given  in  [2].  That  method  would  be  impractical  for  a 
low  level  specification.  The  other  machine  will  be  secure,  however, 
if  it  exhibits  the  same  user-visible  behavior  as  one  that  has  been  proved 
to  be  secure  already.  This  approach  works  if  the  two  machines  have  the 
same  set  of  Inputs  and  the  same  user-visible  state  variables,  as  we  are 
assuming  In  this  section . 
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Formally,  two  machines  (S,sO,T,V)  and  (S',sO',T,V  ) are  defined 
to  be  behavlorally  equivalent  if,  for  every  sequence  of  Inputs, 

tl,«*«,tn. 


V(sO(t 1. . . tn) ) “ V (sO' (t 1 . . . tn) ) . 


This  means  that  both  machines  produce  the  same  outputs  (values  on 
visible  state  variables)  for  all  time  starting  with  the  given  initial 
states. 

Pictorially,  behavioral  equivalence  is: 

1 1 . . . tn 

sO — — I " >s 

4 4 


t tl. . .tn  t 

sO' ►s' 

Figure  3.  Behavioral  Equivalence 


where  4 > means  that  the  two  states  have  the  same  values  on 

visible  V-functlons. 


PROOF  TECHNIQUE 

The  definition  of  behavioral  equivalence  yields  naturally  to  an 
inductive  proof  technique.  We  will  call  the  relation  V(s)  « V (s') 
the  behavioral  equivalence  relation  (BE).  It  would  suffice  to  show 
that : 

1.  The  pair  of  initial  states  sO,  sO'  satisfies  BE,  and 

2.  If  (s,  s')  satisfies  BE  then  for  all  inputs  t in  T,  (st,  st') 
satisfies  BE, 

that  is,  each  possible  state  transition  preserves  BE. 

As  often  happens  in  inductive  proofs,  the  induction  hypothesis 
has  to  be  stronger  than  the  statement  to  be  proved.  We  will  usually 
need  additional  relations.  Many  additional  relations  arise  from  the 
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fact  that  visible  state  variables  are  often  references  to  derived 
V-functlons.  Consequently,  BE  must  be  supported  by  relations  among 
the  hidden  primitive  V-functlons  that  define  the  visible,  derived 
ones.  Furthermore,  both  levels  individually  must  work  "properly",  and 
this  means  that  a number  of  relations  that  are  fundamental  assumptions 
in  the  design  are  needed.  These  relations  insure  that  we  consider 
only  "consistent"  states. 

The  proof  starts  with  BE  alone,  but  the  additional  relations 
suggest  themselves  during  the  proof.  The  technique  of  generating 
relations  as  needed  is  familiar  from  the  top  level  to  model 
validation,  where  we  started  with  relations  expressing  the  axioms  and 
generated  several  more  relations  embodying  design  invariants. 
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SECTION  V 


BEHAVIORAL  IMPLEMENTATION 


In  defining  behavioral  equivalence,  it  was  convenient  to  assume 
that  both  machines  had  the  same  set  of  Inputs  and  the  same  set  of 
visible  state  variables.  The  required  state  variables  can  always  be 
added  to  a machine  described  by  a lower  level  specification,  as 
derived  V-functions.  Matching  the  Inputs  is  harder.  In  a multilevel 
specification,  the  transitions  resulting  from  inputs  in  a lower  level 
are  often  more  primitive  that  those  in  higher  levels.  It  may  take  a 
long  sequence  of  lower  level  inputs  to  produce  the  same  effect  as  one 
upper  level  input. 

Given  the  machine  described  by  a lower  level  specification,  we 
will  construct  a new  algorithmic  machine  that  accepts  the  same  inputs 
as  the  upper  level  machine.  The  transition  caused  by  an  upper  level 
input  is  the  net  effect  of  the  corresponding  sequence  of  lower  level 
transitions.  This  new  algorithmic  machine  can  then  be  compared 
directly  with  the  higher  level  machine  for  behavioral  equivalence. 

The  algorithmic  machine  has  the  same  inputs  and  visible  state 
variables  as  the  high  level  machine,  but  has  the  hidden  state 
variables  of  the  lower  level  machine. 

A mechanism  for  translating  upper  level  inputs  in  this  fashion  is 
already  available:  abstract  programs.  An  abstract  program  translates 
an  upper  level  input  into  a sequence  of  lower  level  Inputs. 

An  abstract  program,  as  described  by  SRI,  uses  the  functions  of  a 
lower  level  specification  and  the  control  constructs  of  some  formally 
defined  programming  language,  li/hlle  the  details  of  the  control 
constructs  have  not  been  specified  by  SRI  and  will  not  be  specified 
here,  we  can  imagine  that  a small,  simple  set  like  succession, 
if-then,  and  whlle-do,  are  used.  Some  remarks  on  other  likely 
characteristics  of  an  abstract  programming  language  will  appear  later 
in  this  section  and  in  Section  VII. 

The  construction  of  a new  algorithmic  machine  from  a lower  level 
specification  and  a collection  of  abstract  programs,  one  for  each 
upper  level  0-function,  is  illustrated  in  Figure  4.  The  figure  points 
up  a flaw  in  the  use  of  more  primitive  machines  to  implement  a virtual 
environment:  a single  input  will  produce  a sequence  of  changes  in 
visible  state  variables,  rather  than  the  single  change  specified  in 
the  top  level.  The  sequence  of  changes  can  obviously  transmit  more 
information  than  the  net  change. 
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EFFECTS  ON 
USER-VISIBLE 
STATE  VARIABLES 


UPPER  LEVEL  INPUTS 
(O-FUNCTION  CALLS) 


ALGORITHMIC 

MACHINE 


Figure  4.  Behavioral  Implementation 
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The  seriousness  of  this  intermediate  state  problem  depends  on  the 
real-world  implementation  of  the  kernel.  Usually  kernel  routines  are 
not  interruptible  by  their  caller,  and  any  changes  they  make  in  memory 
contents  would  not  be  observable  to  the  calling  program  until  the 
kernel  has  returned  control  to  it.  There  are  still  two  danger  spots, 
however:  output  devices  and  concurrently  executing  processes.  A 
succession  of  changes  on  the  screen  of  a CRT  caused  by  a kernel 
routin'’  is  certainly  "visible",  and  communicates  more  information  than 
the  image  that  remains  at  the  conclusion  of  the  routine.  Also,  if 
there  is  a concurrently  executing  program  (especially  on  another 
processor  of  a multiprocessor),  it  might  be  affected  by  access 
permission  changes,  which  happen  in  an  observable  order,  caused  by  a 
kernel  routine. 

If  all  the  changes  in  visible  V-functlons  occur  in  just  one  of 
the  lower  levels  transitions  and  in  all  the  other  lower  level 
transitions  no  changes  on  visible  V-functlons  occur,  then  there  are  no 
visible  intermediate  states  and  behavioral  equivalence  is  possible. 
This  restriction  is  so  severe  that  it  is  likely  to  be  impractical.  It 
would  be  more  practical  to  hide  intermediate  states  Instead,  by 
keeping  visible  effects  hidden  during  the  executions  of  kernel 
routines.  In  other  words,  so-called  visible  state  variables  need  not 
be  visible  at  all  times,  but  only  between  top  level  transitions. 


DEFINITION  OF  BEHAVIORAL  IMPLEMENTATION 

An  upper  level  specification  is  behavlorally  Implemented  by  a 
lower  level  specification,  using  a set  of  abstract  programs,  if  the 
upper  level  machine  defined  by  the  specification  is  behavlorally 
equivalent  to  the  algorithmic  machine  defined  by  the  abstract  programs 
acting  on  the  lower  level  specification. 

Behavioral  implementation  is  proved  just  as  behavioral 
equivalence  would  be  proved,  namely,  inductively,  with  the  help  of  a 
sufficiently  large  set  of  relations.  Showing  that  a relation  is 
preserved  by  the  net  effect  of  an  abstract  program  is  a special  case 
of  the  task  of  showing  that  a program  entered  with  an  input  assertion 
true  finishes  with  an  output  assertion  true.  (See,  for  example, 

[21].)  Each  relation  serves  as  both  an  input  and  an  output  assertion. 

An  abstract  implementation  associates  an  abstract  program  with  each 
upper  level  input.  When  the  program  is  entered  in  a particular  lower 
level  state,  the  result  is  a path  of  execution  through  the  program, 
determined  by  tests  on  lower  level  state  variables,  yielding  a sequence 
of  lower  level  inputs. 
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Formally,  let  M and  M'  be  machines,  where  M = (S,T,sO,V) 
and  M'  =•  (S' ,T' ,s0' ,V' ) . An  abstract  Implementation  is  a 
function: 

A:  S'  X T ->  T'*, 

where  T'*  is  the  set  of  finite  sequences  of  lower  level  Inputs.  Then 
M is  behavlorally  Implemented  by  M',  using  A,  with  respect  to  a 
relation  R contained  in  SxS'  if 

1.  R implies  BE  (l.e.,  if  (s,s')  is  in  R then  V(s)  » V'(s')), 

2.  (sO,sO')  is  in  R (l.e.,  the  initial  states  are  R-related) , and 

3.  if  (s,8')  is  in  R then  (st,8'A(s' ,t))  is  in  R (R  is  preserved  by 
upper  level  Inputs). 

In  practice,  the  relation  R will  be  a conjunction  of  several 
relations  on  state  variables,  including  BE. 


REMARKS  ON  SYNTAX  OF  ABSTRACT  PROGRAMS 

The  fundamental  requirements  for  abstract  programs  are: 

1.  All  effects  on  lower  level  state  variables  result  from  lower  level 
0-function  calls. 

2.  The  sequence  of  lower  level  0-f unction  calls  is  determined 
entirely  by  the  upper  level  0-function  call  (input)  parameters  and 
the  lower  level  state  variables. 

The  abstract  program  format,  as  an  algorithm  written  in  a 
programming  language,  is  just  a constructive  way  of  defining  the 
sequence  of  lower  level  0-functlon  calls  as  required  by  (2). 

Because  program  proofs  are  necessary  to  show  behavioral 
implementation,  the  semantics  of  the  abstract  programming  language 
must  be  rigorously  defined.  Limitations  in  the  choice  of  control 
structures,  data  types,  and  mathematical  operations  may  have  to  be 
observed  if  program  verification  tools  are  to  be  used. 

A question  that  comes  up  often  in  defining  the  semantics  of 
abstract  programs  is  what  to  do  when  a called  0-function  returns  with 
an  exception  condition.  For  Parnas  specifications,  the  desired  effect 
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of  an  error  trap  is  a transfer  of  control  to  a named  error  handling 
routine.  We  may  treat  a sequence  of  exceptions  xl,  x2,...  as  If  It 
had  been  written  as  part  of  the  effect:  if  xl  then  EC  = 1 else  if  x2 
then  EC  = 2 ...  else  EC  = 0,  where  EC  is  an  auxiliary  state  variable 
used  as  an  error  code.  Control  returns  to  the  abstract  program  in  the 
usual  place  after  the  0-function  call,  and  it  becomes  the 
responsibility  of  the  abstract  program  to  test  the  value  of  EC  and 
adjust  its  flow  or  control  accordingly.  This  will  be  referred  to  as 
the  error  code  approach. 

An  expression  of  the  form  "if  a then  b else  if  c then  d else  e" 
in  a Parnas  effect  section  is  just  an  abbreviation  for  the  logical 
expression  a&b  or  (not  a)&c&d  or  (not  a)&(not  c)&e.  The  value  of  this 
expression  gives  the  same  information  as  if  the  tests  on  a,  c,...  had 
been  carried  out  in  the  indicated  order.  Thus,  in  writing  actual 
specifications,  this  treatment  of  exceptions  can  be  stipulated  for 
verification  purposes  while  the  exceptions  are  simply  listed  in  the 
usual  way  without  the  if  - then  connectives. 

Abstract  programs  may  be  expected  to  have  program  variables  and 
assignment  statements.  Assignments  should  have  program  variables  on 
the  left-hand  side.  These  variables  should  not  be  lower  level  state 
variables,  since  only  0-functlon  calls  should  modify  state  variables. 
Arithmetic  or  boolean  expressions,  using  program  variables  and  all 
state  variables  can  appear  on  the  right-hand  side  of  assignment 
statements. 

Abstract  programs  do  not  need  subroutine  calls,  unless  recursion 
is  their  iteration  method.  Any  temptation  to  use  subroutines  probably 
indicates  a need  for  another  level  of  specification  between  the  upper 
and  lower  levels,  since  subroutines  usually  express  some  sort  of 
primitive  operations. 


SUMMARY 

In  this  section  we  Introduced  the  notion  of  behavioral 
implementation  in  order  to  extend  behavioral  equivalence  to  machines 
that  do  not  have  the  same  inputs.  In  behavioral  implementation  each 
input  of  the  first  machine  is  Implemented  by  a sequence  of  Inputs  on 
the  second  machine.  One  must  prove  that  the  sequence  of  inputs  on  the 
second  machine  produces  the  same  user  visible  effect  as  the  original 
input  on  the  first  machine. 

Abstract  programs  express  the  Implementation  of  the  Inputs  of 
the  first  machine  by  the  second.  They  are  written  in  terms  of  the 
variables  and  0-f unctions  of  the  second,  lower  level  machine, 
plus  program  variables.  They  call  0-f unctions  for  any  modifica- 
tion of  the  lower  level  state  variables. 
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SECTION  VI 


MULTILEVEL  BEHAVIORAL  IMPLEMENTATION 


INTRODUCTION 

To  this  point  our  theory  has  revolved  around  only  two  levels  of  ^ 

specification.  We  have  seen:  J 

1.  How  to  prove  that  a lower  level  behaviorally  Implements  an  1 

upper  level. 

2.  If  a lower  level  behaviorally  implements  a secure  upper  i 

level,  the  algorithmic  machine  obtained  by  using  the 

abstract  implementations  of  the  upper  level  Inputs  in  the 
lower  level  is  secure. 

i 

We  have  also  seen,  in  our  discussion  of  the  SRI  design 
methodology,  that  we  would  like  to  decompose  the  design  of  the 
kernel  into  more  than  two  levels.  In  order  to  apply  the  theory 
for  two  levels  to  multi-level  specifications  it  would  help  to  know 
when  the  implementation  relationship  is  transitive.  That  is, 
if  M"  implements  M'  with  the  abstract  implementation  A,  and  M'  imple- 
ments M with  A’  , can  we  construct,  from  A'  and  A,  an  abstract  implemen- 
tation A"  of  M by  M"?  We  will  show  how  the  construction  can  be 
carried  out  when  a certain  condition  relating  successive  implementa- 
tions is  satisfied. 


ABSTRACT  CONSTRUCTION 


Consider  the  following  situation.  Illustrated  in  Figure  5. 

Hypothesis  1.  We  have  three  levels  of  specification,  the  upper, 
middle  and  lower  levels,  defining  machines  M,  M', 
and  M". 

Hypothesis  2.  The  upper  level  is  behaviorally  Implemented  by  the 
middle  w.r.t.,  a relation  set  R.  This  means  that 
for  all  upper  level  inputs  t,  and  for  all  middle 
level  states,  s',  there  is  a sequence  of  middle 
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level  inputs,  denoted  A(s',t),  such  that  for  all 
(s,s')  in  R,  (st,s'A(s' ,t) ) is  in  R. 

Hypothesis  3.  The  middle  level  is  behaviorally  implemented  by 

the  lower  level  w.r.t.,  the  relation  set  R'.  The 
abstract  implementation  is  denoted  A'.  We  have 
for  all  (s',s")  in  R'  and  all  t'  in  T', 
(s't',s"A'(s",t'))  is  in  R'. 

We  would  like  to  prove  that  the  upper  level  is  behaviorally 
implemented  by  the  lower  level  with  respect  to  some  relation  set,  R". 

1.  We  let  R"  “ RoR'  = <(s,  s")  in  SxS"H-s'  in  S'  such  that  (s,s')  is 
in  R and  (s',  s")  is  in  R'}. 

2.  We  must  now  construct  A".  We  note  the  following: 

a.  A':S"xT'  ->  T"*  can  be  extended  in  a natural  way  to  a map 
S"xT'*  ->  T"*,  also  denoted  A'.  This  is  done  recursively  by 
defining 

A'(s",t't~)  - A'(s"A'(s",t'),t'') 

for  t'*  in  T'*. 

b.  If  (s',s")  is  in  R'  and  t''  is  in  T'*  then  (s't^, 

s"A' (s",  t'') ) is  in  R'.  This  can  be  proved  inductively  on 
the  length  of  t'". 

To  define  A"  we  need  the  following  additional  hypothesis: 

Hypothesis  4 (Well-Definition,  W-D).  If  (sl',s")  and  (s2' ,s") 

are  in  R'  then  A(srt)  = A(s2' ,t)  (See  Figure  6). 

We  now  define  A":S"xT  ->  T"*  via: 

c.  If  there  is  s'  in  S'  such  that  (s',s")  is  in  R'  then 
A"(s",t)  - A'(s",A(s',t)), 

We  note  that  by  the  Well-Definition  hypothesis,  this 
definition  is  invariant  of  the  choice  of  s'. 

We  will  see  below  that  A"  need  not  be  defined  when  s'  does  not 
exist . 

Theorem.  If  hypotheses  1-4  are  true  then  the  lower  level  behaviorally 
implements  the  upper  level  w.r.t.,  the  relation  set  R"  using  the 
abstract  Implementation  A". 
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Figure  6 


The  Well-Definition  Hypothesis 


24 


Proof : 


Fix  (s' ,s")  in  R"  and  t in  T.  We  must  show 
(st,s"A"(s",t) ) Is  in  R".  But  by  definition  of  R"  there  exists 
s'  in  S'  such  that  (s,s' ) is  in  R and  (s' ,s")  is  in  R' . 

(s,s')  is  in  R implies  (st ,s' A(s' ,t) ) is  in  R. 

By  definition  of  A", 


A"(s",t)  = A' (s",A(s'  ,t)). 

Therefore,  s"A"(s",t)=  s"A' (s",A(s' ,t) ).  (*) 

By  remark  2b)  above,  letting  t~  = A(s',t),  we  have 
(s'A(s',t),s"A'(s",A(s',t)))  is  in  R'. 

By  (*)  we  have  (s'A(s' , t ) , s"A" (s", t ) ) is  in  R'. 

Now  we  have  (st , s'A(s' , t ) ) is  in  R and  (s 'A(s' , t ) , s"A" (s", t ) ) is 
in  R'.  Therefore  (st , s"A" (s", t ) ) is  in  R",  as  desired. 


EXPLANATION  OF  WELL-DEFINITION  HYPOTHESIS 

We  saw  in  the  previous  section  that  in  order  to  prove 
transitivity  of  behavioral  equivalence  we  needed  the  additional 
hypothesis : 

v;-D:  if  (sr,s")  and  (s2' ,s")  are  in  R'  then  A(sl',t)  = A(s2' ,t). 

This  hypothesis  was  needed  in  order  to  be  able  to  construct  the 
abstract  Implementation  of  the  upper  level  by  the  lower  level.  The 
problem  essentially  is  that  the  abstract  implementation  of  the  upper 
level  by  the  lower  level  can  only  use  lower  level  V-f unctions,  since 
the  abstract  implementation  of  the  upper  level  by  the  lower  level  is  a 
map  taking  S"xT->T"*.  The  obvious  method  of  composing  the  two 
abstract  implementations  A'  and  A still  leaves  us  with  middle  level 
V-i unctions. 

For  example,  let  t be  an  upper  level  input,  v'  a middle  level 
state  variable,  t'  a middle  level  input,  and  t"  a lower  level  input. 

If  our  abstract  programs  (representing  the  abstract  implementations) 
are  defined  as  follows  (where  "call"  followed  by  an  input  means  apply 
that  input  to  the  appropriate  machine): 

A(s',t)  - if  v'  then  call  t' 

A'(s",t')  - call  t". 
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we  would  expect  to  be  able  to  define  the  Implementation  of  t in  the 
lower  level  as: 


A"(s",t)  - If  v'  then  call  t". 

But  this  Is  not  allowed.  We  have  a middle  level  V-functlon  present  In 
the  abstract  program  of  the  upper  level  by  the  lower  level.  In 
general,  we  just  cannot  get  rid  of  It.  Suppose,  however,  that  we  have 
sufficiently  restricted  the  relation  set  between  the  middle  and  lower 
levels  so  that  for  every  allowable  pair  of  middle  and  lower  level 
states,  the  value  of  v'  Is  a function  of  the  lower  level  state, 
denoted  v'  = f(s").  We  can  then  write: 

A"(s",t)  - If  f(s")  then  call  t". 

The  function  f can  be  expressed  as  a derived  lower  level 
V-function.  The  relation  v'  = f Is  then  added  to  the  relation  set 
determining  R'  , to  make  the  VJ-D  Hypothesis  true.  Now  the  program 
for  A"  Involves  only  lower  level  V-f unctions,  as  desired. 

In  general.  If  all  the  middle  V-f unctions  that  appear  In  the 
abstract  Implementation  of  the  upper  level  by  the  middle  level  are 
functions  of  lower  level  V-functlons,  then  we  can  combine  the  abstract 
programs  of  the  upper  to  middle  and  middle  to  lower  levels  to  get  an 
abstract  Implementation  of  the  upper  level  by  the  lower  level 
Involving  only  lower  level  V-functlons. 

It  can  easily  be  shown  that  If  all  the  middle  level  V-functlons 
referenced  In  the  abstract  programs  are  functions  of  lower  level 
V-functlons,  then  the  Well-Def Inltlon  Hypothesis  Is  satisfied. 

Even  where  this  condition  Is  not  true  at  first.  It  can  sometimes 
be  made  true  trivially  by  adding  derived  V-functlons. 

Consider  the  following  example: 

Let : 

A(s',t)  - If  vr&v2' 

then  call  t'; 

The  value  of  A(8',t)  depends  only  on  the  value  of  vl'&v2'.  It 
may  not  be  the  case  that  both  of  vl',  v2'  are  functions  of  the  lower 
level,  while  at  the  same  time  (vl'&v2')  Is  a function  of  the  lower 
level. 

Let  us  make  a mapping  V-functlon  vtest  In  the  middle  level 
whose  value  Is  vl'&v2'.  We  now  have: 
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A(8',t)  “ If  vtest 

then  call  t'; 

With  this  representation  of  A,  we  can  say  that  all  middle  level 
V-functions  appearing  in  the  abstract  implementation  are  functions  of 
the  lower  level,  even  though  this  was  not  true  at  first. 

In  practice,  what  we  do  to  guarantee  the  existence  of  an  abstract 
Implementation  of  the  upper  level  by  the  lower  level  is: 

1.  Identify  the  middle  level  state  variables  appearing  in  the 
abstract  implementation  of  the  upper  level  by  the  middle 
level,  A. 

2.  If  necessary,  add  derived  V-functions  in  the  middle  level 
to  make  step  3.  possible. 

3.  Express  all  the  middle  level  state  variables  appearing  in  A 
as  functions  of  the  lower  level.  For  each  one,  use  a lower 
level  derived  V-f unction  and  a relation  identifying  it  with 
the  middle  level  state  variable. 


Note  that  if  we  construct  A"  as  above,  we  now  have  appearing  in 
A"  lower  level  V-f unctions  of  two  types: 

1.  those  originally  in  A' 

2.  those  needed  to  map  to  the  V-functlons  in  A. 


SUMMARY 

In  this  section  the  theory  of  behavioral  implementation  was 
developed  for  three  or  more  levels.  It  was  shown  that  under  an 
assumption  called  the  Well-Definition  Hypothesis,  an  abstract 
implementation  of  the  top  level  by  the  bottom  level  can  be 
constructed  from  the  implementations  given  between  successive  levels. 

The  Well-Definition  hypothesis  is  satisfied  if  there  are 
relations  expressing  the  state  variables  used  in  abstract  programs  as 
functions  of  lower  level  state  variables.  Such  relations  are  mapping 
relations  between  successive  levels,  like  BE,  and  are  proved 
inductively  in  the  same  way.  The  functions  thus  shown  to  exist  are 
translated  into  function  subprograms  to  form  an  important  part  of  the 
algorithmic  representation,  as  described  in  Section  VII. 
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SECTION  VII 


ALGORITHMIC  REPRESENTATIONS 


In  the  last  section  we  saw  that  If  the  relations  between  levels 
were  sufficiently  strong,  then  we  could  use  the  abstract  programs 
between  levels  to  mathematically  construct  an  abstract  implementation 
of  the  top  level  by  the  bottom  level*  This  section  shows  how  to  use 
these  abstract  programs  in  an  algorithmic  representation  of  the 
kernel. 

The  idea  is  to  retain  the  abstract  programs  unchanged  as 
subroutines  of  the  algorithmic  representation.  In  doing  so, 
0-function  calls  are  viewed  as  subroutine  calls,  and  references  to 
derived  functions  or  to  higher  level  V-functions  are  viewed  as  calls 
on  function  subprograms.  The  complete  algorithmic  representation 
Includes : 

1.  the  original  abstract  programs  between  all  successive  levels, 

2.  function  subprograms  to  calculate  derived  function  values,  and 

3.  function  subprograms  to  calculate  higher  level  primitive  state 
variables  from  lower  level  state  variables. 

V-function  and  0-function  references  in  the  final  programs  must 
all  belong  to  the  bottom  level,  and  the  V-functlons  must  be  primitive. 


EXAMPLE 

Figure  7 shows  three  specifications.  The  top  one  is  the  upper 
level  specification  for  a machine  with  one  data  structure,  a list,  and 
one  0-function,  BEHEAD,  which  removes  the  first  element  of  the  list 
each  time  it  is  called,  until  the  list  is  empty.  The  visible  part  of 
the  list  shortens  by  one  element  each  time  BEHEAD  is  called.  This 
visibility  requirement  is  embodied  in  a derived  V-function  VLIST  which 
returns  zero  for  the  elements  that  have  become  hidden.  The  primitive 
V-functlon  LIST  is  entirely  hidden. 

The  second  specification  describes  a middle  level  llnked-llst 
machine  on  which  the  upper  level  will  be  Implemented.  Note  that  the 
two  visible  V-functions  of  the  upper  level,  LENGTH  and  VLIST,  also 
appear  in  the  middle  level,  although  here  they  are  both  derived. 

Their  presence  is  necessary  for  behavioral  equivalence. 
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Hidden  V-function  LIST(i) 

Visible  V-function  LENGTH 

0-function  BEHEAD: 

Effect:  if  'LENGTH'  / 0 

then  LENGTH  = 'LENGTH'  - 1 
and  (V  i)  if  1 £ i < 'LENGTH' 

then  LIST(i)  = 'LIST'(i  + 1) 

Visible  Derived  V-function  VLIST(i): 

Derivation:  if  1 £ i £ LENGTH  then  LIST(i)  else  0 


Hidden  V-function  VALUE(i) 

Hidden  V-function  PTR(i) 

Hidden  V-function  HEAD 

0-function  CHOP: 

Effect:  HEAD  = PTR('HEAD') 

Visible  Derived  V-function  LENGTH: 

Derivation:  COUNT (HEAD) 

Hidden  Recursive  V-function  COUNT(l): 

Derivation:  if  i = 0 then  0 else  1 + COUNT(PTR(i) ) 

Visible  Derived  V-function  VLIST(i): 

Derivation:  VALUE(WALK(HEAD,i) ) 

Hidden  Recursive  V-function  WALK(j,i): 

Derivation:  if  i = 1 then  j else  WALK(PTR(j ) ,i-l ) 


Visible  V-functlon  LENGTH 
Hidden  V-function  STACK(i) 

0-function  DROP:  Effect:  LENGTH  = 'LENGTH'  - 1 

Visible  Derived  V-function  VLIST(i): 

Derivation:  if  1 £ i £ LENGTH 

then  STACK(LEHGTH  -1+1) 
else  0 


Figure  7.  Example  Specifications 
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Note  also  that  two  of  the  derived  V-functions  are  defined 
recursively.  This  Imposes  an  obligation  to  prove  the  convergence 
of  these  definitions. 

A CHOP  operation  Is  provided  In  the  middle  level,  and  using  It, 
the  upper  level  operation  BEHEAD  can  be  Implemented  with  the  following 
abstract  program: 


Program  BEHEAD: 

If  HEAD  ^ 0 
then  call  CHOP 

The  third  specification  describes  a stack  machine  which  also 
Includes  the  visible  V-functlons  of  the  upper  level.  Its  job  Is  to 
Implement  the  middle  level  0-f unction,  for  which  It  provides  a simple 
0-functlon  DROP  which  merely  lowers  the  stack  pointer.  The  abstract 
program  for  CHOP  Is: 


Program  CHOP: 

If  LENGTH  ^ 0 
then  call  DROP 

Even  for  such  a small  system,  the  proof  of  behavioral 
equivalence  Is  tedious  enough  so  that  It  will  not  be  given  here, 
nor  will  the  proof  of  convergence  of  the  two  recursive  functions  In 
the  middle  level.  In  developing  the  algorithmic  representation, 
however,  we  should  be  aware  that  at  least  BE  Is  satisfied  between  each 
of  the  pairs  of  levels.  Since  we  have  given  corresponding  V-functlons 
the  same  names,  BE  can  be  stated  as: 

LENGTH  = length'  = LENGTH" 

and  (BE) 

LIST(l)  = LIST'(l)  = LIST"(1) 

where  one  prime  (' ) refers  to  the  middle  level,  and  two  to  the  lower. 

The  next  step  Is  to  check  the  VJ-D  Hypothesis  to  establish 
transitivity.  W-D  will  be  satisfied  In  particular  If  each  middle 
level  V-functlon  appearing  In  the  abstract  program  for  BEHEAD  Is  a 
function  of  the  lower  level.  However,  the  lower  level  does  not  contain 
enough  Information  to  determine  HEAD,  the  one  V-functlon  that  occurs. 

In  this  case  we  are  able  to  take  advantage  of  the  tactic  suggested  In 
Section  VI.  Since  the  test  In  the  BEHEAD  program  Is  only  for  HEAD 
^ ',  we  can  define  a new  middle  level  V-functlon  STOP  which  Is 
sufficient  to  handle  the  test  and  which  Is  a function  of  the  lower 
level.  Let  STOP  be  specified  by: 
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Hidden  V-f unction  STOP: 

Derivation:  HEAD  = 0 

Clearly  BEHEAD  can  now  be  rewritten  In  terms  of  STOP  as: 

Program  BEHEAD: 

If  not  STOP 
then  call  CHOP 

We  now  have  to  substantiate  the  claim  that  STOP  Is  a function 
of  the  lower  level.  The  following  relation  will  be  proved: 

STOP  « (LENGTH"  =0). 

To  prove  this  relation  we  observe,  first,  that  by  BE, 

LENGTH  = LENGTH' 

so  that  It  suffices  to  show  that: 

STOP  = (LENGTH'  = 0) 

But  LENGTH'  = COUNT(HEAD),  and  It  Is  easily  shown  from  the  derivation 
of  GOUNT  that  COUNT (1)  - 0 If  and  only  If  1 - 0.  It  follows  that 
LENGTH'  = 0 If  and  only  If  HEIAD  = 0,  as  required. 

Since  STOP  has  been  established  as  a function  of  the  lower  level, 
we  can  regard  the  reference  to  STOP  In  BEHEAD  as  a function  call,  and 
It  remains  only  to  Implement  a function  subprogram  to  calculate  It. 

The  subprogram  for  STOP  would  be: 

Function  subprogram  STOP: 

If  LENGTH"  = 0 
then  STOP  = true 
else  STOP  » false 

Finally,  we  must  be  sure  that  all  other  derived  V-f unctions 
needed  for  the  Implementation  have  been  provided.  In  this  case,  we 
still  need  a function  subprogram  for  VLIST,  say: 

Function  subprogram  VLIST(l): 

If  1 < 1 1 LENGTH" 

then  VLIST (1)  - STACK(LEHGTH"  -1+1) 
else  VLIST(l)  - 0 
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The  two  function  subprograms  above,  plus  the  rewritten  program 
for  BEHEAD  and  the  original  program  for  CHOP,  constitute  the  algorith- 
mic specification  for  the  BEHEAD  system,  in  terms  of  the  STACK  system 
at  the  primitive  level. 


SUMMARY 

The  algorithmic  specification  language  can  be  the  abstract 
programming  language,  extended  to  permit  subroutines  and  function 
subprograms.  This  choice  of  language  makes  the  verification 
requirements  clear  cut.  If  an  algorithmic  representation  in  another 
language  is  to  be  verified,  the  best  bet  is  to  construct  the 
algorithmic  representation  as  described  here,  using  the  abstract 
programming  language,  and  then  prove  equivalence  between  the  two. 

The  algorithmic  representation  suggested  here  consists  of  the 
abstract  programs  already  written,  plus  some  function  subprograms 
needed  to  implement  mappings.  If  behavioral  implementation  has  been 
proved  as  in  Section  V,  using  a relation  set  strong  enough  to 
guarantee  transitivity  as  in  Section  VI,  and  the  calling  mechanism  is 
correct,  then  only  the  new  function  subprograms  need  be  verified  to 
complete  the  proof  of  the  algorithmic  representation. 
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SECTION  VIII 


SUMMARY  AMD  CONCLUSIONS 


In  this  paper  we  have  explored  the  techniques  by  which  one  would 
go  from  a top-level  formal  specification  of  the  kernel  to  an 
algorithmic  representation  of  the  kernel.  The  method  recommended  Is 
to  write  successively  lower  level  specifications,  each  describing  a 
machine  closer  to  the  hardware,  and  each  one  Implemented  by  the  next 
machine  using  abstract  programs  written  In  a simple  abstract 
programming  language  with  no  calls  except  to  lower  level  functions. 

The  last  specification  should  have  as  primitives  the  elementary 
statements  and  built-in  subroutines  of  the  implementation  language. 

Behavioral,  or  black  box,  equivalence  between  abstract 
machines  was  defined  In  terns  of  user-visible  state  variables. 
Behavioral  implementation  is  the  result  of  applying  the  abstract 
Implementation  methodology  to  the  goal  of  behavioral  equivalence. 

A technique  based  on  preserving  a set  of  relations  was 
outlined  for  the  proof  that  each  level  behaviorally  Implements  the 
one  above.  The  set  of  relations  Includes  the  behavioral  equivalence 
relation  (BE).  Abstract  programs  are  used  to  express  the  implementa- 
tion of  upper  level  inputs  via  sequences  of  lower  level  Inputs. 

With  three  or  more  levels  of  specification,  the  abstract  programs 
between  the  successive  pairs  of  levels  can  be  combined  Into  a single 
overall  Implementation  of  the  top  level  by  the  bottom  level  If  the 
Well-Def Inltlon  Hypothesis  (U-D)  is  satisfied.  It  will  be  satisfied 
If  each  state  variable  or  test  appearing  In  an  abstract  program  Is 
expressible  In  terms  of  lower  level  state  variables. 


The  abstract  programs  form  the  core  of  an  algorithmic 
representation.  Function  subprograms  are  then  added  to  calculate  all 
tested  values  and  parameters  In  the  bottom  level.  The  verification  of 
these  function  subprograms  completes  the  proof  that  the  abstract 
machine  described  by  the  algorithmic  representation  Is  behaviorally 
equivalent  to  the  top  level.  If  the  top  level  Is  proved  secure  with 
respect  to  a suitable  set  of  axioms,  the  algorithmic  machine  Is 
secure. 
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